ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group94b.txt/000040_icon-group-sender _Sun Sep 4 22:49:35 1994.msg

Internet Message Format | 1995-02-09 | 6KB

Received: by cheltenham.cs.arizona.edu; Sun, 4 Sep 1994 18:30:53 MST
To: [e-mail]
Date: 4 Sep 1994 22:49:35 GMT
From: [e-mail] (Marc Espie)
Message-Id: <34ditv$[e-mail]>
Organization: Ecole Normale Superieure, PARIS, France
Sender: [e-mail]
References: <[e-mail]>, <347vun$[e-mail]>, <[e-mail]>
Subject: Re: Icon - still alive??
Errors-To: [e-mail]

In article <[e-mail]>,
Richard L. Goerwitz <[e-mail]> wrote:
>In article <347vun$[e-mail]> [e-mail] (Nick Williams) writes:
>>
[some deleted to satisfy my news-poster]
>
>As I pointed out before, Icon has an improved C calling interface that
>allows you to dynamically load functions into the run-time system.  So
>all you have to do to call a C function is to put it into a dynamically
>loadable library, and load it from your Icon program.  No recompilation
>of the Icon source is needed.  I like this.  There are even some exam-
>ples in the new documentation for Icon 9.0.

How many architectures does that new call work under ? Not too many I think...
A perfect example of how general and elegant that mechanism is :-( (I'd like
it to work on every machine myself).

>
>>Forcing programmers to go hack the RTL code from which icont and iconc
>>are made or to write C function wrappers to system routines (plus Icon
>>wrappers as well), then relink the relevant libraries and executables
>>(or use loadfunc()) just to make them think twice before they use a
>>system dependent function is CRAZY!
>
>Again, I just don't agree.  If loadfunc() isn't elegant enough, then an
>improved interface should be developed at some point.  In theory it is
>nice to have a language be all things to all people.  But once a lang-
>uage comits to this philosophy, it's hard to know when to stop.  And the
>result can be ugly and messy.  Far uglier and messier than loadfunc() -
>for which there is perfectly good sample code in the Icon docs.

Just some new simple calls would help icon apply to some domains for which
it becomes quite suited. For instance, writing a graphics interface to a
text-oriented program would be a cinch, provided you have the specific codes
dealing with spawning other programs/interpreting their input/output in a
non-blocking way... perfect application of Icon in my opinion:
text parsing + graphics. Personally, I think the setenv() system call is not
so interesting, but routines to deal with sockets would enable you to write
MANY interesting applications that you currently CAN'T write:

a WWW browser in Icon, for instance. Should not be that difficult...
Icon already knows about GIF files, and is VERY well suited for parsing
generalized text files. The big problem being having to use systems to get
stuff through connections, where everything could be done in Icon.

>
>>Indeed, and why are they putting in graphics extensions? because they
>>are *useful* to have (though _I_ don't use them often); the same would
>>apply to adding fork(), exec() and the like (system() is portable, but
>>limiting, not to mention dangerous).
>
>Here's a prime example.  Creation of a new process in Unix is not atomic.
>You have to copy the current process, then overlay it.  This is pretty
>system dependent.  You mentioned setenv() above.  I don't believe that
>the Mac has environment variables per se.  Getenv() is marginally useful
>for passing information about the environment to Icon (e.g. if you want
>to know what TERM type you have under Unix).  I've never needed setenv()
>within Icon, myself, though.  Not so say someone wouldn't.  But then I
>could see how almost every platform-specific facility might be useful
>at one time or another.  That doesn't mean I want to see them as part
>of the core Icon language definition.

Take your prime example and revert it: look at co-expressions under Icon.
Not exactly a simple mechanism, quite messy to implement on a new machine,
and liable to crash every machine with limited stack-space (just out of
curiosity: does ProIcon on the Mac have co-expressions ? If so, how does
it work ?)
On the other hand, if we wanted REAL subprocesses under Icon, the semantics
would have to match very closely co-expression calls to be natural. I don't
quite see how you can do that without extensive surgery to the Icon code.
I myself believe it would be a very natural extension of the current Icon code,
and rather independent of the way it would be implemented. fork() ?
CreateNewProcTags() ? Nope. I want an Icon subprocess, saying something like:

p := process(thingy)
and then I say something like every e:=(expression1|expression2)@p to send
icon values to p and get some results back.
 - complex values should be COPIED over, unless you want to have to deal with
shared memory issues.
 - not everything is clear about non-blocking issues. Something involving the
semantics of &fail would probably be necessary...

>
>To back off a moment, let me just repeat that your opinion is perfectly
>reasonable, and I'm sure many others share it.  There's another side,
>though, and that's the one I happen to be on.

Not really a problem for you, especially if that kind of augmented behaviour
is user-definable when installing Icon.

On the other hand, I noticed a dire problem while playing around with 9.0:
it seems that the compiler, even without call by name of proecedures, does
NOT prune out unused procedures from its list.
Funny but sad when you link with graphics to use the standard WOpen
and get all the widgets pulled in :-(. Definitely
to be fixed if the IPL is to be part of Standard Icon soon.
--
[nosave]<http://acacia.ens.fr:8080/home/espie/index.html>
`Ayuka no koto... suki dayo.' (KOR, Ano Hi ni kaeritai)
`$@0>@n(J $@$N$3$H!<9%$-$@$h!#(J' ($@$"$NF|$K5"$j$?$$(J)(B
    Marc Espie ([e-mail])